Mixing TEX & PostScript : The GEX Model

VTEX is a (commercial) extended version of TEX, sold by MicroPress, Inc. Free versions of VTEX have recently been made available, that work under OS/2 and Linux. This paper describes GEX, a fast fully-integrated PostScript interpreter which functions as part of the VTEX code-generator. GEX offers one-pass compilation of text (TEX) and graphics and thus easy incorporations of graphics files (.eps) and inline PostScript code (PStricks, PSfrag) within a document. While it is this graphics support which is of primary interest to the end users, the presence of the PostScript interpreter within TEX and its ability to provide feedback to TEX raises interesting questions about mixing text and graphics in general and leads to new graphics-oriented packages. This article serves as a short introduction to GEX, seeking to explain the design issues behind GEX and the extensions which now become possible. Unless specified otherwise, this article describes the functionality in the freeware version of the VTEX compiler, as available on CTAN sites in systems/vtex. What did GEX come from? During the early work on the VTEX PDF backend circa 1998 it became apparent that the only way the backend can handle PStricks graphics is by incorporating a limited PostScript interpreter. GEX (which stands for Graphics EXtensions and is to be pronounced g-e-ks) arose primarily from the author’s misguided optimism about the amount of work required. By the time GEX fully supported PStricks, the code amounted to more than 20,000 lines of C++ code, supported almost the entire PostScript language, and even went beyond it. GEX has become powerful enough to handle not only PostScript files (.eps) but also the common inline PostScript graphics packages (PStricks, PSfrag, XYpic, or Seminar). In addition, it has become possible to design new macro packages with GEX in mind. While the .eps file and inline PostScript inclusion is the main attraction to the end user, this article has very little to say about it. This is because from the end-user standpoint, using GEX amounts to using standard and familiar commands like \includegraphics or \begin{pspicture} and seeing the results appear as expected in the output. Instead, we will concentrate on the design issues and the extensions. What is GEX ? GEX is a graphics counterpart to TEX. The basic design assumes that TEX is responsible for handling of the text; GEX is responsible for processing the graphics components of the document. Both TEX and GEX contribute to the output; since the overall handling of the document is TEX’s responsibility, TEX has overall control. Usually, but not always, GEX functions within the TEX \shipout routine and accepts responsibilities which would otherwise be given to a DVI driver. In more interesting cases, GEX functions during the TEX formatting phase; when so doing, it is capable of returning information to TEX and thus influencing TEX formatting. Since GEX may exercise subtle influence on TEX (load fonts, or change TEX registers), GEX is optional in VTEX implementations: the default operation of the program is with GEX off; it is enabled by a command-line switch. TUGboat, Volume 21 (2000), No. 3 — Proceedings of the 2000 Annual Meeting 251 Alex Kostin & Michael Vulis Of the four primary output modes of the VTEX compiler (DVI, HTML, PDF, PostScript), GEX is currently supported with two: PDF and PostScript. The majority of GEX-related activities are identical in these two modes. Where a behavioral difference is desired, a macro writer can use the \OpMode count primitive (with magic values of 0,1,2 and 10 for DVI, PDF, PS, and HTML output modes). In PDF mode, GEX is basically a PS7→PDF compiler; in the PS mode, it is a PS7→PS compiler which reinterprets input PostScript and produces output similar to what would be produced by printing PDF to PostScript, albeit faster, often tighter and cleaner. (One of the benefits of this in comparison with DVI7→ PS drivers is the combination of the fonts and other resources that are often repeated in included .eps files.) While GEX is a PostScript language interpreter, it is not 100% PostScript; there are subtle design differences, that while not impeding the ability of GEX to process standard PostScript code, allow new applications. The basic design paradigms During the design of GEX it has become apparent that a number of extensions will be needed to be added to TEX to support the extra functionality. In all cases, the basic approach was to try to keep the TEX syntax as close to the standard as possible, and avoid introducing additional keywords. Most of the TEX language extensions are merely \specials which are understood and resolved by the \shipout code in VTEX. Thus, VTEX syntax would not have new words like \pdfimage or \pdfoutline; these would be backend \specials. In practice, we did end up with adding some primitives, but these were primarily new count and skip registers. In designing the syntax of the \specials themselves, an attempt has been made to avoid dependency on the PDF output mode. This makes them either applicable or at least safely ignorable in other operation modes of VTEX (DVI, HTML), not just in the PDF and PostScript modes, where GEX is fully operational. Thus, VTEX’s \special never uses PDF-specific code. While a direct write to the output is supported (with \special{!=...}, analogous to \pdfliteral{...} in pdfTEX), it is generally discouraged. Finally, wherever possible, the \specials are screened from the user, mostly by means of extending the graphicx package. 1 There are also PostScript language extensions in play. How does it work The basic model of TEX-GEX interaction is the two \specials: • \special{pS: .....} with the argument containing valid PostScript code • \special{ps: .....} with the argument being a name of PostScript file to include When the backend sees one of these \specials, it passes it to GEX for compilation. (In PDF mode, with GEX off, it is simply thrown out; with GEX on, it is compiled. In PostScript mode, with GEX off, the parameter is pasted to the PostScript output, as in traditional DVI7→PS drivers; with GEX on, it is re-compiled). Prior to giving control over to GEX, VTEX updates the information in PostScript’s graphics state (setting the coordinates for the current point, for example). Upon the return from TEX, the relevant parts of the PostScript graphics state are given back to TEX. Because of the need to support inline PostScript packages the information about the current font is also shared between TEX and GEX. For example, passing \special{pS: currentfont setfont} to the PostScript interpreter is entirely legal (and is done by PStricks); but the design implication is that GEX is aware of the currently used TEX font and can access it by itself. Access may mean actually loading the font and executing the instructions in the font file; this would happen, for example, if one writes \special{pS: gsave currentfont 2 scalefont setfont 0.5 0 0 setrgbcolor [4 1] 0 setdash (Test stroke) false charpath stroke grestore}